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The NASA STI Program Office ... in Profile 


Since its founding. NASA has been dedicated to 
the advancement of aeronautics and space science. 
The NASA Scientific and Technical Information 
(STI) Program Office plays a key part in helping 
NASA maintain this important role. 

The NASA STI Program Office is operated by 
Langley Research Center, the Lead Center for 
NASA’s scientific and technical information. The 
NASA STI Program Office provides access to the 
NASA STI Database, the largest collection of 
aeronautical and space science STI in the world. 
The Program Office is also NASA’s institutional 
mechanism for disseminating the results of its 
research and development activities. These results 
are published by NASA in the NASA STI Report 
Series, which includes the following report types: 

TECHNICAL PUBLICATION. Reports of 
completed research or a major significant phase 
of research that present the results of NASA 
programs and include extensive data or theoreti- 
cal analysis. Includes compilations of significant 
scientific and technical data and information 
deemed to be of continuing reference value. 
NASA’s counterpart of peer-reviewed formal 
professional papers but has less stringent 
limitations on manuscript length and extent of 
graphic presentations. 

• TECHNICAL MEMORANDUM. Scientific and 
technical findings that are preliminary or of 
specialized interest, e.g., quick release reports, 
working papers, and bibliographies that contain 
minimal annotation. Does not contain extensive 
analysis. 

CONTRACTOR REPORT. Scientific and 
technical findings by NASA-sponsored contrac- 
tors and grantees. 


• CONFERENCE PUBLICATION. Collected 
papers from scientific and technical confer- 
ences, symposia, seminars, or other meetings 
sponsored or cosponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, technical, 
or historical information from NASA programs, 
projects, and missions, often concerned with 
subjects having substantial public interest. 

• TECHNICAL TRANSLATION. 
English-language translations of foreign scien- 
tific and technical material pertinent to NASA’s 
mission. 

Specialized services that complement the STI 
Program Office’s diverse offerings include creating 
custom thesauri, building customized databases, 
organizing and publishing research results . . . even 
providing videos. 

For more information about the NASA STI Pro- 
gram Office, see the following: 

Access the NASA STI Program Home Page at 
http://www.sti.nasa.gov 

• E-mail your question via the Internet to 
help @ sti .nasa.gov 

• Fax your question to the NASA Access Help 

Desk at (301) 621-0134 

• Telephone the NASA Access Help Desk at 

(301)621-0390 

• Write to: 

NASA Access Help Desk 
NASA Center for AeroSpace Information 
800 Elkridge Landing Road 
Linthicum Heights, MD 21090-2934 
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Summary 

Over the past several months, major industry vendors 
have made a business case for the network computer as 
a win-win solution toward lowering total cost of owner- 
ship. This report provides results from Phase I of the 
Ames Research Center network computer evaluation 
project. It identifies factors to be considered for deter- 
mining cost of ownership; further, it examines where, 
when, and how network computer technology might fit 
in NASA’s desktop computing architecture. 

Executive Summary 

CIO Vision — Doing More for Less 

NASA, like other government agencies and industry, 
is being compelled to find more effective ways of 
doing business which will enable the agency to do 
more for less — faster, cheaper, better. In a period of 
downsizing and declining budgets, NASA must partner 
with industry to achieve ways of accomplishing its 
ever-increasing mission with less resources, a fact 
especially true in the case of information technology. 

To respond in pan to the question of how NASA can 
do more for less while enhancing productivity, the 
Ames Research Center Chief Information Officer 
(ARC CIO) established the Network Computer 
Technology Evaluation Team. The role of the team 
is to partner with industry and evaluate for NASA the 
benefits and future implication of emerging network 
computer technology (NCT) to NASA. This report 
summarizes the team’s views and findings regarding 
NCT during Phase I of the evaluation. 

Network Computer Technology and the CIO Vision 

The most visible and significant component of NCT is 
the network computers themselves. Network computers 
(NCs) are information appliances that provide basic 
desktop functions which include, but are not limited to, 
e-mail, spreadsheet, word processing, calendaring, 
presentation, data entry, point of transactions/point of 


sales, and World Wide Web browsing. Typically, NCs 
have a display, keyboard, system unit, and network 
connection, but no hard disk or floppy drive. Because 
NCs typically have no local disk or persistent storage, 
they rely on a server system to provide access to 
applications, data, and documents. 

NCs and NCT address the CIO Vision of doing more 
with less by seeking improvements in end-user produc- 
tivity while reducing capital, maintenance, and support 
costs. End-user productivity has always been an issue 
in enterprise computing. In the days of timesharing, 
users shared a host mainframe computer with character 
based terminals. Communication and interaction 
between users was good, but the functionality of the 
terminals was limited compared to the displays of 
today. The performance of a single host architecture 
did not scale well with increasing numbers of users and 
thus imposed a cap on end-user productivity. However, 
end users did not have to be concerned with tasks such 
as application maintenance and backup of their data. 

The introduction of personal computers (PCs) sought to 
break free from the bottlenecks of a single shared host 
and provide greater functionality. Only one person used 
the PC at a time and there was no competition for 
resources such as machine cycles and storage. As a 
result, there was an immediate perception of improved 
productivity because of the increased responsiveness of 
the system. On the other hand, these desktop computers 
were not normally interconnected, and communication 
and data exchange between users flagged. PCs also 
required a significant amount of “care and feeding” 
on the part of end users. Later, the PCs increasingly 
became networked, but still largely remained “mini- 
mainframe islands.” 

NCT aims to continue the delivery of better function- 
ality and responsiveness to the end user while retaining 
the inherent system administration “best practices” of 
host based computing. User interaction and display 
operations take place on the NC. Application manage- 
ment, system administration, and some computational 
tasks take place in the more easily controlled and 


maintained environment of the centralized server. 

Other duties such as access control, configuration 
management, security and integrity, interoperability, 
and system reliability are also better executed from a 
central server by qualified support staff. Consequently, 
end users can spend less time doing these things and 
more time being productive at their jobs. 

In addition to productivity improvement, NCs have the 
potential of achieving operational cost savings over 
PCs. Industry studies indicate projected cost savings of 
between 26% and 39% per unit. These savings are in 
lower costs for initial hardware procurement, software, 
technical support, and systems administration as well 
as end-user operation. However, it is not clear that 
these studies have taken into account factors relevant 
to the NASA environment. Network and server impact 
is an example of such a factor. Also, current NASA 
data do not include cost components for end-user 
operation. Such differences have further complicated 
comparisons and determination of total cost of 
ownership (TCO) benefits. 

There are special considerations that will affect the 
deployment of NCT. The local area networks and 
existing servers will need adequate capacity to 
accommodate any increase in demand for network 
bandwidth and processor availability. In addition to 
having enough capacity, the network and server 
architecture that supports NCs must be robust and 
reliable. If users are to depend on NC devices for their 
general computing and communication needs, then the 
resources on the servers must be available on demand 
24 hours a day, 7 days a week. Steps will be needed to 
ensure rollover to backup systems in the event of a 
failure in any critical component. 

Deployment of NCs may, in fact, result in startup costs 
associated with migration and infrastructure upgrades. 
While some engineering models seek to project this 
impact, all make simplifying assumptions that may 
make them less relevant to the NASA environment. In 
order to get a better picture of how NCs will affect the 
NASA information technology (IT) infrastructure, 
better performance metrics are needed that take into 
account the local system and network architectures as 
well as the mix of applications used. These metrics can 
be developed through a limited deployment of NCs 
throughout the enterprise. A limited NC deployment is 
planned for Ames Research Center during Phase II of 
the NCT evaluation. 

Another consideration for deployment is the cost for 
training system administrators, technical support staff, 
and users during and after a migration to NCs. The 


extent of this training or retraining depends on the NC 
architecture used and the applications to be supported. 

Perhaps the foremost issue affecting the success of 
NCT in the enterprise is the availability of applications 
for NCs. The first NCs were mostly display terminals 
that relied on the server to execute and store the 
application. The early acceptance of these devices 
rested on their ability to access existing applications 
such as office productivity suites — the disadvantage 
being that users must share the computational capacity 
of the server. 

The next wave of NCs will support direct execution of 
Java applications which are downloaded from the 
server. Users of these NCs will not have to share the 
computational load of the server. However, until now 
there has not been a viable Java based office produc- 
tivity suite. Nevertheless, the future is encouraging and 
vendors are expected to release these products during 
the first and second quarters of calendar year 1998. 

Java is key to achieving the greatest advantage of the 
NC. The largest cost savings cited by the industry 
studies are for those NC systems which rely on client- 
side execution of Java applications. These Java 
applications are developed from software elements 
called “classes” that are dynamically loaded as 
needed. Within this architecture, updates to software 
can be done at any time, often without notice by the 
user. Moreover, deployment of applications and main- 
tenance of consistent versions across all platforms 
become automatic. 

Java’s “write once, run anywhere” design goal means 
that only one version of an application is needed for 
all ranges and makes of computers. Further, the Java 
security model provides a starting point for implement- 
ing security policies in the NC environment. Many of 
the acknowledged systems administration best prac- 
tices are already implemented as part of the Java 
computing platform. 

The differences seen between NC architectures and 
their rapid evolution suggest that there is no “one size 
fits all” NC solution today. NCs do not yet provide the 
high-end multimedia capability of more expensive PCs. 
However, it is expected that NCs will be able to offer 
the core productivity tools which are necessary for 
organizations to operate. While NCs cannot currently 
replace scientific and engineering workstations, they 
can reduce the requirement of having a second system 
to provide those basic desktop functions. However, 
further tests conducted by the U.S. Navy (Naval 
Command, Control and Ocean Surveillance Center) 
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may indicate some progress in areas such as informa- 
tion display and command and control. 

Over the next six months to a year, many advances 
are expected in performance and capability of NCs as 
well as the emergence of new Java based applications 
which will encourage a reexamination of current 
notions of enterprise computing. It has been customary 


to focus on the metaphor of the desktop. The emer- 
gence of NCs and NCT requires looking outside the 
“box” of the desktop to consider general purpose 
computing in the context of a network of enterprise 
services delivered to the user in the same way 
documents and content are delivered by the web. 
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Technology Assessment and Issues 

During the period from January to June 1997, the Blue 
team conducted an assessment of NCT using informa- 
tion collected from industry reports, vendor documents, 
interviews with experts, and tests performed in the 
Ames NCT laboratory. In the course of this work, the 
Blue team identified technology issues that have a 
bearing on deployment of NCT within NASA. These 
issues are: 

• Maturity, development, and growth of NCT 

• Costs and savings 

• Productivity gains and management improvement 

• Network and server impact 

• Training and migration 

• Matching NCT alternatives to target applications 

• The need for better metrics 

• The roles played by Java and legacy applications 
The following is a discussion of the issues. 

Maturity, Development, and Growth of NCT 

NCT is a new technology. The systems available to the 
Blue team all were introduced or went to market within 
the last year. However, portions of the technology have 
been around for some time, as shown in table 1. 

The NC-S systems are based upon X-terminal 
technology which appeared in the late eighties and 
early nineties. NC-S systems still support X-terminal 
technology today as well as the newer intelligent 


content architecture (ICA) protocol that improves 
performance over low speed network connections. 

At the same time, the web project was getting under 
way at CERN (the European Laboratory for Particle 
Physics, Switzerland), and the Oak project began at 
Sun Microsystems, which ultimately led to Java. The 
National Center for Supercomputer Applications later 
introduced a graphically oriented tool known as Mosaic 
to browse the web. These technologies came together 
in 1994 with the creation of Java “applets” or programs 
loaded into web browsers using the Internet. 

Not long after the public announcement of Java in the 
spring of 1995, Oracle made trade press headlines with 
its proposed diskless Java processor called the Network 
Computer. Oracle also announced that it had enlisted 
Apple, IBM, Netscape, Sun, and others as partners 
willing to build devices that adhere to the NC refer- 
ence profile (NCRP). This was the beginning of the 
NC-C class of machines. Within a year and a half, 
most of the vendors who are participating in this 
evaluation announced their NC-C and NC-S systems. 
NCT consequently is based on mature technologies as 
old as TCP/IP and X- Windows. However, integration of 
the technologies that produced the NC is new. This 
presented some difficulties for the evaluation because 
key pieces of the technology were not in place during 
the evaluation period. For example, it was hard to do 
side-by-side comparisons of all NC categories. Not all 
the NC-S operating systems supported local Java 
execution and some NC-C devices did not have 
software for X- Windows and ICA protocols. Different 
protocols were also used among the NC vendors for 
booting the devices. This meant that there was very 


Table 1. NCT historical timeline 


1984 

X-Windows 

1989 

X-terminals 

October 1990 

WWW project begins at CERN in Switzerland 

January 1991 

Sun begins the Oak project which later spawned Java 

1993 

Mosaic distributed by NCSA 

1994 

Citrix Winframe intelligent content architecture technology 

May 1995 

Java introduced by Sun 

September 1995 

NC concept introduced by Oracle 

1996 

NCD, HDS, and others announce NC-S class systems 

February 1996 

Sun announces Java based microprocessors 

May 1996 

Java based office suites, prototype NC-Cs demonstrated at JavaOne conference 

October 1996 

Java stations introduced by Sun 

October 1996 

NetPC concept announced by Microsoft 

January 1997 

Ames initiates NCT evaluation 
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limited interoperability between NCs and boot servers 
from different vendors. During the evaluation, NCs 
could not boot across subnet boundaries using dynamic 
assignment of IP addresses. More importantly, the 
number of Java enterprise applications was small 
compared to those currently available for UNIX and 
Microsoft Windows operating systems. Nevertheless, 
NCT is developing and growing rapidly. 

Table 2 gives an indication of the timeline for 
predicted NCT developments and enhancements. 

Many of the problems listed above were expected to 
be addressed within a year. NC-C systems such as 
the Sun JavaStation were expected to be able to boot 
across subnets by fall 1997. First customer shipments of 
Java based office application suites may be occurring 
by the end of the first quarter of calendar year 1998. 
Microsoft has also announced multi-user session 
support for Windows NT 4.0. Faster processors for all 
the NC systems will be available by January 1998. 

Other developments such as the availability of Java 
based office suites are expected to occur by the spring 
of calendar year 1998. During this time, there will also 
be several enhancements to the Java Runtime environ- 
ment and associated packages. New visually oriented 
development environments such as Sun’s Project 
Studio and IBM’s Visual Age for Java will make it 
easier for application developers to create programs for 
the NCs. Despite the relative youth of NCT, the pace 


of growth in terms of numbers and functionality is 
increasing rapidly. It is highly likely that within the 
next year or two the capabilities and usage of NCs will 
expand beyond call centers, point of sales, and kiosks 
to office desktops and general purpose computing. 

Costs and Savings 

Initial Capital Costs 

Much of the NC news in the trade press also 
emphasizes the initial NC hardware cost savings in 
addition to TCO. While reports of $300 and $500 NCs 
make for eye-catching headlines, costs for all of the 
NCs installed in the NCT laboratory range from around 
$600 to $1500. The approximate costs of NCs in each 
category are shown in table 3. 

NCs are approximately only half the cost of a typical 
new PC or Macintosh. However, trends in the industry 
suggest that the prices of PCs are dropping. For 
example, within the last year PC manufacturers have 
attempted to meet NC competition by introducing 
“cheap PCs” which cost in the neighborhood of 
$800 without the monitor. The last entry in table 3 
shows the projected cost of converting an existing PC 
or Macintosh to an NC-C by installing an appropriate 
Java enabled browser. Sun is also intending to release 
their NC-C operating system, JavaOS, for older 
Intel 486 machines in order to convert them to NC-Cs. 


Table 2. Projected NC developments 


Fall 1997 
Winter 1997-1998 

Spring 1998 
Fall 1998 

Cache storage in some NC-C systems 

4x to 5x processor speedup 

Introduction of 100BaseT network support 

NC-S systems get local Java execution 

Full CD quality audio output, audio input 

First customer shipments of Java based office suites 

First shipments of Java based office suites prototypes, NetPCs 

Booting of NC-C system across subnets, boot from multiple vendor hosts 

SmartCard and public key encryption available to customers 


Table 3. Comparison of initial hardware purchase costs 

System type 

Cost of system unit* Monitor Other** 

Total 

PC or Macintosh 

NC-S 

NC-C 

NetPC 

Existing desktop 

$2436 $765 $0 

670 765 0 

742 765 0 

1000 765 0 

0 0 300 



*Ames GMR contract prices are shown for PC or Macintosh. The NetPC cost is an estimate based on published reports. 
**For existing desktops, the cost shown is for software that converts the system into an NC-C. 
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The reason NCs cost less to buy than “traditional” PCs 
is because of their reduced functionality (i.e., the hard- 
ware they don’t have, such as hard disks, floppy drives, 
etc.). There are cost factors other than acquisition of 
the NCs themselves. Depending on the enterprise IT 
infrastructure, networks and servers may need to be 
upgraded. Also, there are costs associated with migra- 
tion of the support staff and users. These issues are 
addressed later in this report. 

Total Cost of Ownership 

The issue of TCO gets most of the attention with regard 
to NCs. TCO is the annual cost of operating and main- 
taining a desktop system. The Gartner Group (ref. 1) 
has done several studies on TCO, and their figures are 
often quoted. The cost components of the Gartner TCO 
model are capital, technical support, administration, 
end-user operations, and local area network (LAN). 
Table 4 summarizes the Gartner Group TCO compo- 
nents as life cycle costs for one year. 

Capital. The description of the hardware client capital 
costs was given in the preceding section. Other capital 
costs include that of the operating system software and 
applications software. There may be savings for soft- 
ware costs if better site licenses and right-to-copy 
terms are negotiated with the vendor. While these 
costs would be incurred for either NCs or PCs, there 
are potential additional savings from vendors of Java 
applications because of lower development costs and 
elimination of platform specific versions. 

Technical Support . The cost of providing help to users 
has been projected by industry accounts to be less for 


the NCs. The rationale behind this is that having fewer 
functions leads to fewer problems and difficulties. Also 
the use of simpler applications written in Java may 
lead to fewer trouble calls. Furthermore, many of the 
NC attributes which give way to a single point of 
control may contribute toward lessening the need for 
technical support. This is an area of speculation until 
measurements can be made in a later phase when NCs 
are actually deployed to users as desktop replacements. 

Administration. Cost savings in ongoing administration 
of existing desktop systems have already received 
considerable attention. Recent NASA studies have 
shown that consolidation of desktop services will lead 
to reduced operating costs. The resulting post consoli- 
dation per seat costs for system administration are in 
the range of $1 100 to $1300 for PC/Mac for traditional 
desktop systems (ref. 2). The Gartner study asserts that 
such costs can be further reduced 20% to 25% by 
enforcing system administration best practices. In a 
recent Datamation article (ref. 3), some of these best 
practices were identified as: 

• Standardized hardware and software 

• Central software distribution and management 

• Asset-management programs 

• Deployment of desktop management suites 

• Improved training programs 

Additionally, other second-level best practices, such 
as similar and consistent file systems, also make for 
easier administration. 


Table 4. Gartner Group TCO components (life cycle costs for one year) 


One time and annual costs (first year) 

Win95 PC 

NC-C 

NC-S 

NetPC/NT 5.0 

Capital (one time) 

$1850 

$980 

$1015 

$1733 

Technical support 

1066 

870 

859 

970 

Administration 

945 

440 

460 

422 

End-user operations 

3464 

1799 

2219 

2073 

Desktop costs 

7325 

4089 

4553 

5198 

Network capital (one time) 

682 

689 

882 

664 

Network technical support 

638 

611 

638 

567 

Network administration 

552 

230 

310 

406 

Network end user 

588 

392 

392 

434 

Network costs 

2460 

1922 

2222 

2071 

Total costs 

$9785 

$6011 

$6775 

$7269 

Reductions (Win95 base) 


39% 

31% 

26% 


Source: Adapted from Gartner Group and Datamation. 
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The problems with exploiting best practices in a 
research environment include (1) the diversity of 
systems and platforms needed to support widely 
differing requirements and (2) the resistance to change. 
Migration to best practices in such an environment 
depends on establishing standards which will be valid 
across the range of platform types. Also needed is the 
willingness on the part of users to change system 
management methods. Experience has shown that the 
migration to best practices has not been overwhelm- 
ingly popular. For these reasons, it is difficult to project 
the cost of migration to best practices in a diverse 
computing environment. However, NCs can potentially 
provide an alternate approach toward the benefits of 
best practices. 

Many best practices are built into the NC architecture. 

It is easier to have standard hardware configurations 
because NCs have limited options and bear similarities 
to one another. By putting the applications that NCs 
use on the server, it is straightforward to standardize 
software. Server repositories for NC software by default 
centralize software distribution and management. With 
NCs, the emphasis for asset management and desktop 
management suites is also shifted to the server. 

It is projected that after the switch to NC-C systems 
some enterprises will be able double the number of 
desktop systems maintained by a single system 
administrator. 

According to the Ames Research Center Desktop 
Systems Management Consolidation study, current 
estimates of the number of systems maintained by a 
system administrator are 30 for UNIX workstations, 

90 for Macintoshes, and 75 for PCs. If the degree of 
improvement is consistent for NC adoption, a NASA 
system administrator could be managing at least 
150 NCs. 

End-User Operations . As can be seen in table 4, 
end-user operations account for a sizable amount of 
the total costs in the Gartner model — 26% to 35%. 
Equivalent data for Ames are not available and are 
difficult to project. However, using the Gartner numbers 
as a starting point, it may be reasonable to assume 
that end-user operations costs could drop 2% to 9% 
with NCT. 

Network Costs. According to Gartner Group estimates, 
the effect NCT will have on network costs is notice- 
able but not significant. In addition, the Gartner 
numbers show that the network costs are only about 
one half of the desktop costs. This suggests that any 
network cost improvements will have only a small 
effect on the overall total cost. 


Productivity Gains and Management Improvement 

A study of Forbes 100 IT managers regarding NCT was 
done in 1997 by the Yankee Group. The results show 
that there is greater importance placed on other issues 
than TCO. In fact, TCO ranked fifth after centralized 
management, unifying software platform, central 
storage, and lower initial price. These issues are 
associated more with maintaining or improving 
productivity and gaining greater control over the 
enterprise’s resources. 

Centralized Management 

One of the perceived problems associated with 
individually operated and maintained enterprise 
desktops is the difficulty in controlling or managing 
this resource to ensure productivity. Experience has 
shown that aspects of control affecting productivity 
include: 

• Access 

• Configuration 

• Security and integrity 

• Application software 

• Interoperability 

• Reliability 

Access. Unless otherwise configured, many desktop 
systems are “open” and, as such, accessible to anyone. 
On the other hand, it is common for staff to go from 
one desktop to another and yet still expect to access 
their own computing environment. This notion of a 
network identity is not often implemented with PCs, 
although a form of it has existed for years with UNIX 
systems. 

Both the NC-S and NC-C systems depend on a server 
authenticated login. Since the user’s identity is man- 
aged on the server, users can migrate from one NC to 
another and still establish their own session from the 
selected server. All of the NC systems tested in the 
NCT laboratory required some sort of user id and 
password before establishing a session. The NC-S 
systems ask the user to select the server prior to login. 
Once selected, a login screen from the server is dis- 
played. The NC-C systems are by default connected to 
a particular boot server which presents a user id and 
password query panel after power-up. The notion of 
network identity with the NC-C systems is currently 
managed by a Sun product called NIS. While a related 
product, NIS+, may be acceptable in the existing 
enterprise security framework, NIS is not, owing to 
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security concerns. It is understood that other alterna- 
tives to NIS are being considered by the NC-C vendors. 

The SmartCard is another form of access control 
currently under development by NC vendors. 

SmartCard readers will be available in some NCs. A 
SmartCard contains a small embedded processor and 
memory, which in turn holds an individual’s identity 
information, encrypted keys, and computing 
environment profile. With a SmartCard, users can take 
their environment with them and securely access those 
parts of the enterprise computing system for which they 
are authorized. NC vendors are also predicting that 
SmartCard-enabled NCs will be located in public 
places such as airports and hotels. Pending universal 
adoption of SmartCard standards, a person could travel 
with only a SmartCard and not carry a laptop computer. 
Upon inserting the SmartCard into, say, an airport 
lobby NC, travelers could establish their own desktop 
environment and securely perform tasks such as e-mail 
or document processing. Some NC vendors such as 
Network Computer, Inc. (NCI) have based their entire 
offering on SmartCard authentication. 

Configuration. Productivity losses can arise from the 
diversity of system configurations within an enterprise, 
even if all systems are the same kind. Systems support 
staff indicate that the variations of system options — 
peripherals, installed software, and file system 
configurations — make their work more difficult and 
time consuming. The NCs provided for this evaluation 
all limit the hardware and software options and 
functions. The NCs have the features that most users 
will need (such as mouse, audio, printer port, and 
serial port), and some even have a PC manufacturer 
interface adaptor (PCMIA) slot. Few of the NCs tested 
had a local hard disk. The HDS Supra did have a 
floppy drive as an external accessory and an optional 
PCMIA local hard drive for local booting. The NC-S 
systems also had nonvolatile read only memory for 
network boot parameters. 

Security and Integrity. A hostile attack on a conven- 
tional desktop system can be costly not only for the 
potential loss of data and confidentiality, but also for 
staff productivity which will be lost in trying to recover 
from the damage. Such attacks often occur when a 
virus is introduced from a download or from a floppy 
disk. The attack may read sensitive data from the 
desktop hard drive or, even worse, erase its contents. 
Without a local hard disk, NCs appear to be relatively 
immune to virus attacks. It is expected that security 
and integrity of NCs will be a function of the security 
measures and policies in place on the servers and 
throughout the enterprise network. 


Application Software. The enterprise’s application 
software must be available on demand to all workers 
who need to use it. Ordinarily this software must be 
installed on each desktop system. Version upgrades 
are a problem in large enterprises owing to the time 
needed for installation on all systems. This approach to 
promulgating software and upgrades takes time on the 
part of system administrators and adversely affects user 
productivity. Staff cannot access the system while 
software is being installed. The NCs bypass local 
installation either by running the application on the 
server (NC-S case) or by downloading the software on 
demand (NC-C case). 

Interoperability. Systems must be able to communicate 
and share data with one another. If they cannot, time 
can be lost in finding alternative ways to move data 
between systems. The extreme case is when data are 
manually transcribed. Through the use of servers, 

NCs appear to go a long way toward achieving inter- 
operability. System administrators can ensure that 
server based applications do interoperate and that 
documents and data produced by one user can be read 
by another. 

Reliability. Desktop systems which are unreliable and 
do not perform as needed have a serious impact on 
productivity. When systems do fail, repair should be 
quick in order to minimize disruption. During the 
evaluation period, none of the NCs ceased to work 
owing to a breakdown. However, installation was 
simple — only five cable connections were needed 
before power-on — and it would have been easy to 
replace the entire system unit with a spare and return 
it to a repair facility. No applications or data would be 
lost since they are stored on the server. The reduced 
functionality and number of options for NCs also means 
that there are fewer components to fail. 

However, there are some reliability concerns for using 
NCs. These concerns involve dependence of NCs on 
the network and server systems, which is analogous to 
desktop telephones and the phone company network. 

If the network goes down, telephones are useless. 
Nevertheless, like telephone companies, IT operations 
have learned how to build fail-safe networks and 
redundant servers that can survive most system failures. 

Unifying Software Platform 

The motivation behind having a unifying software 
platform is to be able to run the same software on 
systems large and small as well as systems with 
different architectures. The productivity savings then 
come from reduced duplication of effort, which comes 
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about in two ways: less time is spent maintaining an 
application if there are fewer versions of it in use, and 
less time is spent by users in learning and operating 
key enterprise software if it operates similarly 
regardless of where it is run. 

The NCs examined in this study seek to provide such a 
unifying software platform. NC-S devices allow access 
to legacy applications as well as newer tools. One 
version of the software resides on the server where it 
executes. It has the same look and feel on every NC-S 
device. The NC-C devices load the components of an 
application from a master copy on the server. Although 
an application executes on local NCs, it is the same 
application for all NCs. Furthermore, since the NC-C 
devices run Java programs, there needs to be only one 
version of the code for all platforms — the NC-S, NC-C, 
and existing desktop systems all have the ability to run 
Java programs if the Java Runtime environment is 
available on that system. 

Centrally Managed Storage 

Management of storage with conventional desktop PCs 
is commonly the responsibility of the user. Keeping 
applications current, organizing and accessing docu- 
ments, and backing up data are some of the tasks 
which depend on due diligence on the part of the users. 
While the costs for accidental loss of key applications 
may be limited to time, the loss of documents or data 
can be of greater consequence. One of the attractions 
seen for NCT is the centralization of user application 
and File storage on systems that are meticulously 
maintained and backed up routinely. With central 
storage, it is easier (and more likely) to recover from a 
disaster when the proper procedures are performed by 
trained system administration staff. 

Network and Server Impact 

Incorporation of NCT within an enterprise will have an 
impact on the existing network and server architecture. 
Both the NC-S and NC-C architectures will place 
bandwidth demands on the network as well as impose 
greater workloads on the part of servers. 

The network and server play essential roles in either 
of the NC architectures. Network and server reliability 
is critical. Applications usage patterns will probably 
require some reengineering of server connections to 
provide greater peak throughput, and server capability 
may need enhancement. Follow-on testing phases of 
this project will test typical configurations and applica- 
tions usage to contrast and compare to classical usage. 


Nework Impact . The way NC-S and NC-C systems use 
the network differs. While NC-S systems do not require 
application software to be downloaded from the server, 
they do need to have constant interaction over the 
network to update their displays and transmit user 
input. Using X- Windows protocols, approximately 
15 to 30 users can be handled over an ethernet 
segment. Switched ethernets can accommodate 100 
to 200 similar NC-S systems (ref. 4). Greater network 
throughput is possible with NC-S systems that employ 
ICA protocol. However, there are greater processing 
demands for NC-S and server systems with ICA. 

NC-C systems, unlike NC-S systems, execute appli- 
cations locally rather than on a remote host server. 

These applications, which exist as collections of Java 
classes, are loaded on demand over the network. 

Display updates and user input are handled locally on 
the NC-C system without accessing the server. This 
leads to network behavior which is more like web 
browsing. That is, there is not a steady stream of 
display images and graphical data but rather inter- 
mittent requests for web pages and software compo- 
nents. Using a model provided by Sun Microsystems 
(ref. 5), the level of network interaction is measured in 
HTTPOPS (HyperText transfer protocol operations per 
second). NC-C systems like the JavaStation exhibit 
about 1 HTTPOPS average with 10 HTTPOPS peak. 

The Sun model assumes an average of 10,000 bytes 
transferred per HTTPOPS. Using these figures and 30% 
TCP/IP overhead, roughly 20 NC-C users will saturate 
an ethernet segment. Using a switched ethernet will 
potentially support 5 to 10 times this number of users. 

Tests conducted in the Ames NCT laboratory involved 
running a heavy database application (PowerSoft) on a 
133 mHz Pentium system with four NC-S users on a 
dedicated lOBaseT ethernet segment. The heaviest net- 
work usage occurred when all systems initiated a boot 
sequence at the same time — approximately 36% of 
network capacity. The sustained network load through- 
out the rest of the test was roughly 4%. Similarly, the 
period of greatest network load for the NC-Cs was at 
boot time, when two NC-C systems consumed 36% 
of network capacity. However, network usage while 
running applications such as Java based word process- 
ing and spreadsheets programs was less than 4%. 

In summary, NC-S and NC-S systems will apparently 
impose a similar load on the network yet with different 
sorts of network traffic. This traffic load is expected to 
vary, with the greatest network demands occurring 
during NC booting. While 20 or so users may com- 
fortably share a network segment under normal working 
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conditions, there are likely to be delays if multiple 
users boot at the same time. 

Server Impact. The extent of the server impact also 
differs for NC-S and NC-C systems. Because NC-S 
systems require applications to execute on the server, 
there must be enough processing, input/output, and 
storage capacity to accommodate multiple users. As an 
example, if 22 to 27 NC-S users need to access basic 
word processing, spreadsheet, and electronic mail 
applications, each with a performance level equivalent 
to a 75 mHz Intel Pentium processor, then a 200 mHz 
Pentium Pro uniprocessor is needed. 

Increasing the number of processors on the server will 
support more users or more demanding applications. 
Between 4 and 8 MB of memory must be allocated to 
each user in addition to the memory occupied by the 
operating system and applications. Approximately 
256 MB will be needed to support 22 to 27 NC-S users. 
Disk usage will vary greatly depending on the work 
being done. Enough disk space will be needed for the 
operating system, applications, page swapping, 
temporary scratch space, and user files. The computa- 
tion of the amount of disk space, while enterprise 
dependent, should target having only 5 to 10 users per 
disk drive. 

Just as NC-C systems look more like web browsers 
from a network standpoint, the NC-C server closely 
resembles web servers. Java classes reside on the 
server and are sent to the NC-C in much the same way 
as HTML (HyperText markup language) documents. 
The loads presented by NC-C systems on the server 
differ greatly, depending on usage patterns. The 
demands posed by NC-C booting and web access are 
the lowest, and middleware brokering of distributed 
computing (e.g., CORBA) are the greatest. If 
1 HTTPOPS is assumed for normal NC-C activity, 
then a low-end system equivalent to a Netra j4 would 
be adequate for 20 users. Booting would result in 
3 to 4 MB code image transfers but this would be 
sporadic, especially if the NC-Cs were never switched 
off. On the high end, a Netra j4000-4 would be needed 
to support 50 distributed computing NC-C users. 

Training and Migration 

Introducing NCT into the enterprise will require 
training on the part of users and support staff as well as 
creating migration issues. The amount of retraining will 
vary depending on the existing system environment in 
the enterprise. For example, users who already use 
Windows/NT and Windows applications will make the 
least change by migrating to NC-S systems and multi- 


user Windows/NT servers. While there is more of a 
difference between the Windows and NC-C environ- 
ments, the migration might not be as difficult as expec- 
ted since the user interface is based on the familiar 
web browser model. System support staff will also need 
to be trained in server based NC administration. 

Matching NCT Alternatives to Applications 

NCT, at this time, is not a “one size fits all” 
proposition. The usefulness for scientific, engineering, 
and software development tasks is yet to be demon- 
strated and was not considered in this phase of the 
evaluation. The most likely target applications are: 

• Point of transaction sites 

• Data entry 

• Clerical tasks 

• General office computing (word processing, 
spreadsheet, and electronic mail) 

• Web browsing and intranet 

The NC-S systems form a bridge to legacy applications 
that can run on central servers. Enterprises which 
depend on such applications can use NC-S systems to 
achieve many of the benefits of NCT with minimal 
change to their user operations. This applies particu- 
larly to clerical tasks, general office computing, and 
web browsing. The NC-C systems today do not simi- 
larly support access to legacy applications. However, 
Java based software such as Lotus SmartSuite and 
Corel Office for Java will soon be available. Enter- 
prises willing to develop Java software for point of 
transaction and data entry functions may consider the 
current NC-C systems as an alternative. 

The Need for Better Metrics 

Better metrics are needed to paint a clearer picture of 
how NCT can figure into NASA organizations and 
enterprises. Measurements for existing and NCT 
environments are needed especially in the following 
areas: 

• System administration tasks 

• Server loading under actual conditions 

• Network performance under actual conditions 

• End-user productivity and operations 

• Hardware and software reliability and maintenance 

• Functionality for a larger community of users 
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As discovered in the research of TCO, it is difficult to 
get a better understanding of costs because the industry 
research studies make assumptions and measurements 
which may not be appropriate for NASA. Examples 
include capital costs and end-user operations. It is 
proposed that Phase II of this evaluation focus on 
deploying NCs to staff and monitor the system perfor- 
mance, usage, and support costs as well as overall 
productivity. 

The Roles Played by Java and Legacy Applications 

Java is a key component of the NC-C systems archi- 
tecture. The ability of dynamically loading Java 
programs as needed by an application running on an 
NC-C system is the basis of many of the features of 
this architecture. 

Java is a general purpose computer programming 
language and a new approach for network centric 
computing. Java programs are essentially collections of 
classes which are called up for execution as needed. 
Classes are the patterns or “blueprints” used to con- 
struct the Java objects used in a Java program. Java 
classes can reside locally on a desktop system or 
remotely on an enterprise-wide server. 

Much of Java's importance and appeal arises from its 
ability to reduce costs associated with enterprise 
application software. It is expected that Java will lead 
to lower costs for application software acquisition, 
deployment, and management. 

Application software can be less expensive because 
Java developers can reduce their development time 
and expense. Java has features which promote good 
programming practices and improve programmer 
productivity. 

Deployment of Java applications is potentially simple 
and inexpensive. The Java software components called 
classes can reside in “packages” stored on a central- 
ized server. One copy of a Java class residing on a 
server can be accessed by and shared with all the 
Java enabled desktop client systems in the enterprise. 
Through this process, a user can fetch copies of Java 
classes on demand from the suite of Java packages 
currently installed. Consequently: 

• The number of installations performed is reduced 
dramatically 

• All desktop systems use the same version of an 
application 

• Any updates of Java packages are immediately 
available to all desktop systems in the enterprise 


• One copy of the application can be used on all 
systems and computer platforms which are Java 
enabled 

Java provides an appealing solution for reducing the 
cost of managing applications. The computing archi- 
tecture supported by Java offers the benefits of central- 
ized software maintenance while taking advantage of 
computing cycles available on the NC-C system. 

Having one or a limited number of locations to keep 
applications means that less work is needed to: 

• Limit the number of different application versions 
in use 

• Give users timely access to software upgrades and 
patches 

• Track software assets 

• Reuse classes for in-house developed software 

• Establish centralized management of software 
licenses 

In addition, there are other collateral benefits of Java, 
such as the “sandbox” security model that is available 
in the Java Runtime environment. While users and 
system administrators should always remain vigilant 
regarding good security practices, applications written 
in Java need less attention to maintain a reasonable 
level of safety and security. 

Java based applications require less system resources 
such as memory, a result of loading classes on demand 
and using “automatic garbage collection.” The ability 
to run in “leaner” environments means that an enter- 
prise can utilize desktop hardware which might other- 
wise be considered obsolete. The downside is that there 
is a dearth of enterprise-quality Java application 
software today. 

Java developers are now acquiring the skills needed to 
produce robust applications. What this means is that to 
use the NC-C today an enterprise must be willing to 
use early Java software or internally develop the 
required code. This situation will remain until legacy 
applications are ported to Java or users migrate to 
current Java applications. 

The NC-S systems play the role of bridging the gap 
between new and emerging Java applications and 
legacy code. This advantage will diminish with time 
because the NC-C systems will acquire the X-Windows 
and ICA protocols, developers will eventually port 
their applications to Java, and the NC-S systems will 
become more capable Java clients. 
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Appendix 

NCT Evaluation Project 

Background 

The NCT Evaluation Project reflects the direction of 
the Ames Applied Information Technology Division in 
response to a request from the ARC CIO to evaluate 
for NASA the usefulness of NCT (e.g., NCs, NetPCs, 
Java) and its potential for improving productivity and 
reducing cost within the NASA desktop computing 
environment. The result of this evaluation will be a 
recommendation of an IT strategy for NCT. 

A major core activity of the Division is new technology 
assessment and its infusion into the NASA workplace. 
In that role, the Division is identifying, evaluating, 
demonstrating (testbedding), and integrating promising 
technology to enhance workforce productivity. The 
Division serves as the model and showcase for the 
infusion of emerging technologies through the utiliza- 
tion of Ames IT research in partnership with the 
research efforts of industry and academia. 

Rationale 

The rationale for conducting this NCT evaluation 
centers around the fact that NASA organizations rely 
heavily on desktop PCs to perform daily mission- 
critical tasks. Oddly, the reliability of those systems 
may be a factor which adversely affects user produc- 
tivity, resulting in the PC becoming a victim to its own 
success. For example, since the PC and its software 
have become more sophisticated and complex, system 
configurations can be easily altered by untrained users, 
resulting in downtime. Typical PC problems may take 
hours or even days for so-called experts to fix. Software 
packages often have new features which may not 
justify the time and expense of hardware upgrades, 
installation, and training. Word processors, spread- 
sheets, schedulers, and e-mail are all mission-critical 
productivity tools and therefore should be readily 
available and easy to use, which is sometimes not 
the case. 

TCO studies show that typical desktop PCs cost 
between $5000 and $10,000 per year to maintain, 
with the cost constantly rising. An organization with 
5000 PCs may incur annual costs of $25M to $50M per 
year (see table 4). It is clear that NASA must control 
these costs while still providing the tools necessary to 
perform the mission. 


Project Management 

The NC Blue team is a self-directed work team, 
formed in early November 1996. Individual team 
members were selected by the ARC CIO, from a skill 
mix of various specialized technical areas (e.g., 
technical consulting, advanced networking, IT 
planning, and management). The team has full 
responsibility for the planning, performance, and 
management of the evaluation. The team facilitates 
compliance and commitment to major project 
decisions, issues final decisions on project issues that 
cross organizational boundaries, and is accountable to 
the ARC CIO for work schedules, project costs, and 
achievement of project goals. 

The team has responsibility for articulating Ames 
requirements and evaluation criteria for NCT and status 
report tracking. Further, the team has responsibility for 
the commitment of all resources required to conduct 
the evaluation. 

Aside from the Blue and Red team members, the 
project is supported by a “cast of thousands.” The cast 
includes the NC evaluation support staff, individuals 
(expert and non-expert) who, while not directly 
assigned to the project, act as consultants providing 
the following support: 

• Systems Administration — Installation of NC server 
software, maintenance of user accounts, and 
monitoring of NC demands on server resources 

• Network Administration — Provision of NC to server 
connectivity via the Ames LAN and monitoring of 
NC demands on the network 

• Computer Security Administration — Review of NC 
security issues and security consultation 

• Training Coordination — Provision of training of 
staff and volunteer testers on the NC and the NC 
base applications such as office suites 

• Volunteer Testing — Usage of NC technology in 
addition to or in lieu of current tools with feedback 
on experiences. Initial volunteer testers will be a 
representative sample of the Ames resident staff in 
terms of technical abilities and job functions 

Evaluation Project Approach 

Phase I of the NC evaluation was limited to testing 
performed inside the laboratory area with technical 
users (system, database, and network administrators 
and security experts) performing functions on industry 
loaned NC equipment. In Phases II and III, the 
evaluation moves into a wider Ames community. 
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which will include nontechnical users (administrative 
managers, administrative support, non-IT researchers, 
and students) and organizations that have requested to 
become a part of the evaluation. NCs will be placed at 
the users’ work sites to be used in lieu of their current 
tools with feedback on experiences. 

Initial organizational meetings have begun to discuss a 
Java computing initiative. Industry partners from Sun 
Microsystems and JavaSoft have volunteered to 
provide support in this effort. 

Solicited Industry Partners and NASA Customer 
Involvement 

Throughout the NCT evaluation project, several 
combinations of industry partners and partnership 
arrangements were and are continuing to be developed. 
These partnerships have greatly facilitated this evalua- 
tion and, further, contribute significantly to Ames 
researchers’ knowledge of other advancing technolo- 
gies that can benefit NASA. 

Initial vendor contacts began in late November 1996 
with Oracle and NCI. In early March 1997, Sun 
Microsystems established a special NC support team 
tasked to work with five key government agencies. 
Ames was selected as one of the agencies to receive 
special attention and emphasis. By late May 1997, 
the Blue team and Division staff had seen product 
presentations from nearly all the major NC vendors and 
had populated the NCT laboratory area with loaned 
NCs from five major vendors (Sun, IBM, HDS, NCD, 
and Wyse). The NC Blue team used a variety of media 
types and forums to communicate the goals of the 
project to potential partners in private industry and to 
current and potential customers at NASA. The team 
hosted IT briefings and invited vendors to present 


overviews of their current technology. Many of the 
initial partnerships were formed as an outgrowth of 
those meetings. 

A web site was created, http://mystic.arc.nasa.gov/nct/, 
which describes the project in detail, and the URL 
was widely distributed to potential industry partners. 
Weekly team meetings were held which were open to 
NC evaluation industry partners. Further, the team 
spoke at a variety of systems administration Birds of 
a Feather meetings, and gave numerous tours of the 
NCT laboratory to upper management and staff. 

To date, industry partners directly involved in this 
evaluation include HDS Network Systems, Inc.; 

Network Computing Devices, Inc.; Sun Microsystems, 
Inc.; IBM Corporation; and Wyse Technology, Inc. 

The team’s longer term goals include forming alliances 
with NCI, a spin-off company of the Oracle Corpora- 
tion, and one or more of the Intel based NetPC 
vendors, such as Compaq, Dell, or Hewlett-Packard. 
The support provided by the industry partners extends 
far beyond merely supplying equipment. Expert 
technical support has been included in all cases. 

Established NCT Laboratory 

The NCT laboratory was populated with nine loaned 
NCs from five major vendors (HDS, NCD, Sun, IBM, 
and Wyse). Two vendors (NCD and Sun) included boot 
servers with their NCs. The NC team provided an Intel 
based server and an IBM RS6000 server. The labora- 
tory was configured on an isolated test subnet. One 
dedicated network monitoring system was added to the 
network, and the Intel server was configured with the 
Sun Microsystems network monitoring package for 
detailed network packet analysis. The laboratory 
network is shown in figure 1 . 



Figure 1. NCT laboratory network. 
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Conducted Tests 

Phase I of the NC evaluation was limited to testing 
performed inside the laboratory area with technical 
users (system, database, and network administrators, 
and security experts) performing functions on industry 
loaned NC equipment. The findings are discussed in 
detail in the Technology Assessment and Issues 
section. 

Functionality . The basic functionality the team looked 
for in the various NC architectures included the ability 
to run the standard office applications used throughout 
NASA (e.g., Word, Excel, and PowerPoint) and e-mail 
and web browser capability. During this initial phase 
of the evaluation, the lack of X- Windows and ICA 
protocol support for JavaStations left the team at a 
disadvantage for conducting an apples-to-apples 
comparison of operating scenarios. 

Network and System Loads and Scaling. Tests were run 
to collect initial data on network capacity loadings for 
the network and servers. Four individuals were selected 
to use the HDS and NCD systems to connect with 
PowerBuilder, a database software development tool, 
running on the Intrigue server. In this mode the NCs 
play the role of a terminal sharing the computational 
capacity of a server. 

Desktop Computing Architectures 

The basic variations among four desktop computing 
architectures (traditional PCs, NetPCs, and the two 
NCs) are shown in table 5 and discussed in further 
detail below. 

Traditional PC-Fat Client. The traditional desktop PC 
is one that has a fast processor (Pentium or PowerPC), 
ample memory (>24 MB), local storage, and remov- 
able media (floppy and CD ROM). It is a self- 
contained system in which all operating system code, 
applications, and data reside on the local disk and 
execute on the local processor. Mail and web services 
are the only services that require server access. Most 
administration must be done at the system. It is also 
important to note that the traditional PC has the widest 
variety of vendors and choices. From a price and 
innovation standpoint this is good, but from an overall 
administration standpoint this is a nightmare which is 
directly responsible for the high cost of ownership and 
decrease of productivity in core functions. 

NetPC-Fat Client. The NetPC is an invention of 
Microsoft and Intel. It is basically a locked-down PC 
with the promise of greatly reduced management costs. 


These systems are being designed with the following 
features to reduce the administration costs: 

• Remote power management 

• Automatic system update and application 
installation 

• All state information kept on server 

• Central administration and system lock-down 
features 

The operating system code, applications, and data 
reside on the local disk and execute on the local 
processor. The system itself is physically more secure 
to prevent nonprofessional tampering with the configu- 
ration. This is to reduce the “futz factor.” 

Network Computer. The NC is defined in the NCRP, 
http://www.nc.ihost.com/nc_ref_profiIe.htmL This 
profile was developed by a collaboration between 
Apple, IBM, Netscape, Oracle, and Sun Microsystems 
in July 1996. 

The NCRP is intended to provide a common denomi- 
nator of popular and widely used features and functions 
across a broad range of scaleable network computing 
devices, including PCs. The hardware guidelines cover 
a minimum screen resolution of 640 x 480 (VGA) or 
equivalent, a pointing device (mouse or track ball), 
text input capabilities, and audio output. The agreed 
upon Internet protocols are transmission control 
protocol (TCP), file transfer protocol (FTP), optional 
support of network file system to enable low-cost, 
medialess devices while allowing for persistent storage 
in the network; and SNMP, a protocol enabling the 
distributed management of devices. 

The profile further adheres to web standards HTML, 
HTTP, and the Java application environment, as well 
as to mainstream mail protocols (SMTP, IMAP4, 
POP3) and common data formats such as JPEG, 

GIF, WAV, and AU. Optional security features are 
supported through emerging security application 
program interfaces; security standards are ISO 7816 
SmartCards and the EMV (Europay/MasterCard/Visa) 
specification. The vendors have responded by offering 
products which fall into the two general groups referred 
to as NC-S and NC-C. 

NC-S (Citrix W inframe )-Thin Client. NC-S is the 
Windows/PC equivalent to the UNIX/X-terminal 
model. Specially modified Windows NT* servers 
provide remote multi-user interface capability. The 
client system is usually a diskless display terminal 
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Table 5. Desktop computing architecture summary 


NetPC 


Local storage > ^ MB >16 MB <16 MB* <16 MB 

Memory requirement >to me , \ l ° - t; prvpr 

Use, state location Local Local/Serve, Serve Se v„ 

Applications storage location Local Local Nq 

Removable storage (floppy) Yes Yes 0 Yeg 

Requires network and server to operate No No es 

Application execution location Local Local erver 

^Exception is HDS ©workstation', optional PCMIA hard disk available, local browser, and applications; also local 


Yes 

>16 MB 

Local/Server 

Local 

Yes 

No 

Local 


No* 

<16 MB* 
Server 
Server 
No* 

Yes 

Server 


No* 

<16 MB 

Server 

Server 

No 

Yes 

Local 
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much like the X-terminal. All applications code is 
executed on the server and all applications code and 
files stay resident on the server. Many of these products 
precede the creation of the NCRP and are simply 
adding on Java capability. The major advantage of this 
product group is the seamless ability to run Microsoft 
Office applications on an NT server. 

NC-C (Java)-Thin Client . NC-C is the pure Java 
approach to network computing. This architecture is 
not built on any legacy technology such as X-terminal 
technology. The NC-C systems are designed for exe- 
cution of Java code. Sun Microsystems is the main 
champion of this approach with its Java stations. Java 
applications are stored on a network server. NC-C 
(Java) clients download the needed Java code from the 
server and do local execution. If additional functions 
are needed by the application, then this code is down- 
loaded on demand to the client. Although this approach 


most closely meets the intended goals of the NCRP, it 
also has the following drawbacks: 

• Porting of existing applications to Java is in its 
infancy 

• Java language is still in development 

• Access to other services and functions not ported 
to Java must be done through Java gateway 
applications 

It is important to note that even though NCs are being 
designed to meet the open standards of the NCRP, 
there are substantial differences in how they are booted 
and managed. This means that for the immediate future 
the choice of NC boot and management servers is very 
limited, usually to a product from the same manufac- 
turer as the NC (see the Maturity, Development, and 
Growth of NCT section of this report). 
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